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(57) Abstract 



An automated marketing system provides a full range of services for telemarketing support The automated marketing system may 
include a client profile management system for obtaining data from multiple data providers in different formats and mtegrating the data 
into a standardized client profile database. The automated rnarketing system includes a data warehouse for storing large amounts of data 
regarding potential clients. An automated lead generation system processes the data in the data warehouse to generate leads that fulfill 
certain characteristics corresponding to given marketing campaigns. These leads may be passed to telemarketers who use the leads. The 
results may be fed back into the automated marketing system to update lead generation strategy and to update client data that is stored by 
the automated marketing system. 
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STRATEGIC MARKETING SYSTEM 

TECHNICAL FIELD 

The present invention relates generally to telecommunications 
systems, and more particularly, to a strategic marketing system for telemarketing. 

5 BACKGROUND OF THE INVENTION 

Telemarketing direct mail and direct sale have become more 
widespread in recent years. A diversity of businesses are employing marketing 
to sell their goods and services. One of the goals of such marketing is to 
establish new customers so as to expand the customer base of a business. These 

10 businesses desire to target potential customers who are most likely to be 
effectively solicited by marketing campaigns and contacts. 

Conventional systems identify potential customers for contact by 
telephone numbers or addresses. In general, batches of telephone numbers or 
addresses are placed on contact lists and mass calling mailing or visiting 

15 campaigns are performed. Unfortunately, such mass campaigns are not very 
effective in that they generally have high failure rates. In addition, such 
campaigns utilize a large volume of resources. 

In conventional systems, customer data, including telephone 
numbers and customer names, are typically stored in a large centralized database. 

20 Some conventional calling campaigns query the database for customers based on 
their telephone numbers (e.g., area code and/or three digit prefix). In 
conventional calling campaigns, new marketing strategies and campaigns are 
formulated which query the database for certain criteria related to phone number 
records in the database. Since the database is centralized and very large, such 

25 queries consume significant processing time and are therefore quite time- 
consuming. Furthermore, results from such queries are often difficult to 
effectively employ in a given mass calling campaign. Moreover, marketing 
strategies and campaigns are limited to types and organizations of data within the 
database. 
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SUMMARY OF THE INVENTION 

In accordance with a first aspect of the present invention, an 
automated marketing system includes a client profile management system for 
managing client profiles. The client profiles contain information about clients 
5 for marketing contact The automated marketing system also includes a data 
warehouse system for storing data regarding clients. Lastly, the automated 
marketing system includes a contact infrastructure for querying the data 
warehouse to automatically generate leads of clients to contact by telemarketers. 
The querying entails filtering data in the data warehouse to ensure that the 
10 generated leads are for clients that include certain characteristics. 

In accordance with another aspect of the present invention, a 
computer-implemented method is practiced in an automated marketing system 
that has stored data regarding potential clients. A lead generator is provided for 
generating leads of potential clients to contact by telemarketers from the stored 
IS client data. The lead generator is used to generate leads for a first marketing 
campaign. Results of contacting the generated leads are obtained, and the results 
are used to generate leads that lead generator for a second marketing campaign. 

In accordance with an additional aspect of the present invention, a 
method is practiced in an automated marketing system such that client 
20 information regarding potential clients for telemarketing contact is provided on a 
* per-client basis. The client information is queried to generate a list of leads for 
telemarketing contact. Each lead is associated with a potential client and 
contains contact information for the potential client that fulfills a first set of 
characteristics. The leads are then forwarded to telemarketers. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

A preferred embodiment of the present invention will be described 
below relative to the following drawings. 

Figure 1 is a block diagram illustrating the strategic marketing 
system (SaMS) infrastructure that is suitable for practicing the preferred 
30 embodiment of the present invention. 
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Figure 2 is a block diagram of a contact service infrastructure 

(CONI). 

Figure 3 is an exemplary data structure diagram of a lead record. 

Figure 4 is an exemplary data structure diagram of a lead 
5 distribution record. 

Figure 5 is a block diagram of a computer system that is suitable 
for running CARMA. 

Figure 6 illustrates the logical organization of die client database. 

Figure 7 illustrates data flows within CARMA. 
10 Figure 8 is *a flowchart illustrating the steps that are performed to 

process data by CARMA. - , 

Figure 9 is a flowchart illustrating the steps that are performed to 
apply matching rules by CARMA. 

Figure 10 is a diagram that illustrates the different categories of 
15 rules that are found within die match rule table of CARMA. 

Figure 1 1 is a diagram that illustrates the different types of overlay 
rules that are found in CARMA. 

Figure 12 is a data flow diagram illustrating die data flow for die 
SaMS infrastructure. 

20 DETAILED DESCRIPTION OF THE INVENTION 

The preferred embodiment of the present invention provides a 
strategic marketing system (SaMS) for providing complete marketing services for 
business clients. The preferred embodiment of the present invention is especially 
well adapted for telemarketing. SaMS provides automated data collection, client 

25 management, inventory analysis, decision support, lead generation, campaign 
management, order fulfillment and provisioning, customer tracking and other 
strategic marketing services. . SaMS provides automated feedback of client 
contacts results for updating client profiles. The feedback is also used to 
generate new marketing leads, to formulate new marketing campaigns and to 

30 restrict future client contact, in some instances. 
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The marketing strategies developed with SaMS are directed 
towards individual clients rattier than telephone numbers. A telephone number 
constitutes a property of a client SaMS includes a database for maintaining 
client profile information and large quantities of information regarding clients 
5 may be received from numerous different sources. The data may be received in 
multiple formats and may be of a number of different types. The information on 
clients is utilized to analyze strategic marketing trends and to establish 
population profiles. Enhanced marketing campaigns can be conducted using 
these trends and profiles. As a result, customer leads may be generated that have 
10 a higher success rate and greater efficiency than conventional systems. 

1 . System Overview 

Figure 1 shows an exemplary information system architecture for 
SaMS 100. The various components of the SaMS Infrastructure 100 interact 
15 cooperatively as shown in Figure 1 to provide many targeted marketing 
functions, such as those described herein. The SaMS infrastructure 100 performs 
at least three functions: client management, information management, and 
contact services. 

"Client management" includes the process of identifying, tracking 
20 and managing clients. "Clients" include both current customers and potential 
customers or leads, and therefore many businesses may have hundreds of 
millions of clients. Client management involves obtaining and maintaining 
descriptive behavioral data about clients as individuals. A primary component in 
the SaMS Infrastructure 100 for client management is the Client Acquisition and 
25 Retention Management Architecture (CARMA) 102. CARMA 102 is preferably 
a software system that provides a database and data processing for client 
management. An exemplary embodiment of CARMA 102 is described in more 
detail below. 

"Information management" is the process of collecting, storing, and 
30 managing data that reflects entire client populations and trends. Information 
management provides decision support functions and tools that place raw data in 
context for product and marketing strategies. Information management deals 
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with descriptive behavioral data about generalized client populations. A primaiy 
component for information management is a Decision Support System (DSS) 
104. The DSS 104 consists of a large-scale data warehouse, along with 
processes for collecting, storing, managing, distributing, and analyzing data. In 
5 general, a "data warehouse" is a consolidation of information for many 
departments or "Business Strategy Units" within a company, as well as 
information extracted from outside of die company. An exemplary embodiment 
of the DSS 104 is described below with respect to Figure 12. 

"Contact services" take conclusions drawn from data warehouse 

10 queries and use them to formulate marketing campaigns and to generate leads. 
This process also tracks and manages all contacts made with clients. CONI 106 
provides contact services for die SaMS infrastructure 100. CONI 106 is 
preferably a software system that uses data extracted from die data warehouse of 
the DSS 104, along with specific strategies formulated by a company's Business 

15 Strategy Units to generate leads. CONI 106 interfaces with a Centralized Lead 
Repository (CLR) 108 to manage and track contacts with clients or leads, as 
described below. 

Information regarding such contacts made with clients are fed back 
to the client management function of the SaMS infrastructure 100. As a result, 

20 the client management, information management, and contact services functions 
of the SaMS infrastructure 100 is a cyclic process: the information management 
function puts raw data into context to perform research, draw conclusions and 
form strategies; the contact services function formalizes and implements 
marketing strategies based on the research, conclusions and strategies produced 

25 under the information management function; and the client management function 
identifies and tracks individuals, collects descriptive and behavioral data, and 
provides such data back to the information management function. 

Various data providers 110 provide data to both CARMA 102 and 
DSS 104. The data providers 110 include any source of data input to the SaMS 

30 Infrastructure 100 to provide information on clients. The data providers 110 
consist of both internal data sources 112 and external data sources 114. 
Examples of internal data sources 112 include data feeds from billing systems, 
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customer order entry systems, order provisioning systems, customer databases, 
marketing databases, customer service systems, accounts receivable systems, and 
many others. They may also include input from other components of the SaMS 
infrastructure 100, such as the CLR 108. Examples of external data sources 114 
5 include files of telephone directories, U.S. Post Office directories, credit 
company reports, and many third party data products that provide specific data 
on people. These third party data products may include information such as 
products people buy, where people move to and from, services people utilize, 
and results from telephone surveys on people's interests and needs. External 

10 data sources 114 may also an airlines' frequent flier programs, auto club 
memberships, health club memberships, travel clubs, and magazine 
subscriptions. These data are used to aid in tracking clients via clients' 
memberships and participation in other businesses. 

CARMA 102 collects data about specific clients from the data 

15 providers 110, and uses the data to update client profiles. CARMA 102 then 
feeds any changes in client data to the DSS 104, but in a generalized form. That 
is, CARMA 102 does not send to the DSS 104 specific clients' names and 
addresses, but rather, sends information that reflects generic clients' profiles. 
CARMA 102 sends a unique client identifier with client profile changes, so that 

20 when leads are generated from data in the DSS 104, they can be matched to a 
specific name, address, and telephone number. In general, clients are typically 
identified under the SaMS infrastructure 100 based on their client identifiers, 
which are unique numeric or alphanumeric codes associated with each client 
Client identifiers are maintained in CARMA 102 and the DSS 104. 

25 The DSS 104 also collects data from the data providers 110. The 

DSS 104 typically collects data unrelated to specific clients, but rather groups of 
clients. Such data may include the number of people who moved from one state 
to another, the number of people who purchased both a car and home stereo in 
the same year, or the number of women who own a business and are members of 

30 a political party. The possibilities for data collection by the DSS 104 are 
numerous, and vaiy according to the business needs of the user of the SaMS 
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infrastructure 100. The DSS 104 also collects data from CARMA 102, and other 
sources, as described below. 

The DSS 104 allows Business Strategy Units (BSU) 116 to access 
data stored in its data warehouse. A BSU 1 16 can be a subset of a company 
5 responsible for formulating business, marketing, and sales strategies. For 
example, one BSU 116 can be responsible for international clients, while another 
BSU 116 can be responsible for domestic clients. Alternatively, the BSU 116 
can be the entire company employing the SaMS infrastructure 100. 

Users or BSUs 116 access the data stored in the DSS 104 for 

10 various functions, including data survey, data mining, data drilling, predictive 
modeling, general queries and results delivery. The data survey function helps 
the BSU 1 16 to identify potentially valuable groups of data. The data survey 
function helps the BSU 116 find unanticipated patterns to guide marketing 
decisions. For example, a survey of a data mart 388 (described below) may 

IS discover that 80% of a population in the northeast and with incomes of greater 
than $50,000 use cellular service. The BSU 116 can thereafter determine why 
income and geographic characteristics lead to cellular usage. 

The data surveying function helps identify and classify large 
segments of data. The data mining and data drilling functions qualify these large 

20 segments of data to further identify and quantify business opportunities. Once a 
significant pattern has been established, die pattern can be represented as a 
mathematical model that establishes the correlation between certain 
characteristics (e.g., income over $50,000, northeastern U.S. population, etc.) to 
other characteristics (e.g., cellular users). From these models, the BSU 116 can 

25 create mailing lists of candidates for a cellular direct mail campaign. 

The general query function allows the BSU 116 to perform simple 
queries of data in the data marts via a DSS user interface process. For example, 
the BSU 116 can query the data mart for the total sales in a given year. The 
results delivery function allows the DSS 104 to deliver data in numerous ways, 

30 such as formatted reports, three-dimensional graphics, etc. 

Each BSU 116 performs strategic queries of data in the data 
warehouse of the DSS 104, using certain analytical tools. From the results of 
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these queries, the BSU 1 16 formulates marketing campaigns. The BSU 1 16 then 
uses CONI 106 to implement the selected marketing campaign. As described 
more fully below, the BSU 116 specifies to CONI 106 criteria to use in 
extracting lead data from the DSS 104. Lead data is used to identify client leads, 
5 which are clients to be targeted in the selected marketing campaign. A "lead" is 
typically a client who is a potential customer of the company. Each lead is 
identified by a corresponding, unique client identifier stored in the DSS 104. 
CONI 106 then generates leads or lead records by matching these client 
identifiers with a name, address, and/or telephone number obtained from 

10 CARMA 102 via an operational data collection/distribution process of DSS 104, 
described below with respect to in Figure 3. 

When CONI 106 generates lead records, it places these records in 
the CLR 108. The CLR 108 is a database, smaller than the data warehouse of the 
DSS 104, used to track leads and activities performed on leads. The CLR 108 

15 stores both lead records and lead distribution records. Each lead record, stored in 
the CLR 108, includes fields for client identifier, telephone number, address 
identifier number, and perhaps a field for previous contact. Figure 3 shows an 
exemplary, more detailed, lead record constructed under Informix, showing 
numerous, generally self-explanatory fields. The CLR 108 preferably stores only 

20 one lead record per client The CLR 108 also stores lead distribution records. 
More than one lead distribution record can be associated with each lead record. 
Figure 4 shows an exemplary, more detailed, lead distribution record constructed 
under Informix, showing numerous, generally self-explanatory fields. Each lead 
distribution record includes fields for identifying certain TM/DM centers 118, a 

25 number of records descend to each center, dates, priority codes, etc. 

The lead records generated by CONI 106 and stored in the CLR 
108 are distributed by CONI to one or more Telemarketing/Direct Mail Centers 
(TM/DM centers) 1 18. The TM/DM centers 118 include call centers from which 
telemarketing agents perform client contacts, sales, and services over the phone. 

30 Often, a TM/DM center 118 is located in each "sales city" in which marketing 
campaigns are conducted. However, the TM/DM centers 118 can conduct 
marketing campaigns outside of the cities in which they are located. 
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The TM/DM centers 118 may also include centers from which 
direct mail campaigns are conducted. While die present invention is generally 
described below with respect to a telemarketing campaign performed at the 
TM/DM center 118, those skilled in the relevant art will readily recognize that 
5 the embodiment of die present invention is equally applicable to direct mail 
campaigns. Additionally, the present invention is equally applicable to other 
methods of contacting clients, either physically or electronically, such as via 
e-mail or Internet contact 

Agents at the TM/DM center 118 use the lead records provided to 

10 them by CONI 106 to call or contact clients and perform sales and/or service 
functions. The agents input the results of these contacts to the TM/DM center 
118, which forwards die results to CONI 106. CONI 106 provides information 
from these results back to both CARMA 102 and the DSS 104 as a data provider 
110. For example, if a client is contacted to market to them long distance 

15 service, but the client indicates they prefer to switch their local phone service 
provider instead, an agent records this indication in a file at the TM/DM center 
118. A file of all clients who prefer to switch their local phone service provider 
is then fed, as a data provider 110, to CARMA 102 and the DSS 104. CARMA 
102 uses this information to update the profile of each client included in the file 

20 to indicate this client is interested in switching their local service provider. This 
information is then fed from CARMA 102 to the DSS 104, in the form of a client 
identifier and an indicator that represents an interest in switching local service 
providers, which is stored therein. 

The DSS 104 can also receive information directiy from the 

25 TM/DM center 118 (as a data provider), via CONI 106, indicating how many 
people in a particular city, for example, are interested in switching their local 
service provider. From this information, the BSU 116 can query the DSS 104 to 
determine if enough interest exists in a certain city to formulate a local service 
provider marketing campaign in die city. CONI 106 can then generate leads for 

30 the local service provider campaign. The above example represents one of many 
feedback loops within the SaMS infrastructure 100. 
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When an agent at the TM/DM center 1 18 signs up a new customer 
or makes a sale, the agent inputs an order directly into a customer order entry 
system 120. The customer order entry system 120, in addition to recording and 
provisioning die order, provides update data to the DSS 104 to indicate the 
5 results o£ or information surrounding, the order. For example, if the order is for 
long distance service, the customer order entry system 120 updates the DSS 104 
to indicate this client now subscribes to long distance service. 

The order for long distance service is also provided to National 
LEC Interface System (NLIS) and Quick Preferred Interexchange Carrier (PIC) 

10 systems 122. The NLIS and Quick PIC systems 122 provide the order to the 
client's Local Exchange Carrier (LEC) 124 so that the LEC can convert the 
client's PIC at the appropriate local switch. The NLIS and Quick PIC systems 
122 are described in detail in U.S. Patent Application entitled "System and 
Method for Real Time Exchange of Customer Data Between 

15 Telecommunications Companies," (COS-96-069) and assigned to a common 
assignee of the present application. The architecture of die TM/DM centers 118, 
customer order entry system 120, and NLIS and Quick PIC systems 122 enable 
the processes of contacting a client, selling long distance service to that client, 
recording and provisioning the order for long distance service, and converting the 

20 client's PIC at the LEC 124 switch to all occur within only a few minutes. 

The NLIS and Quick PIC systems 122 also provide data to the DSS 
104 for unsolicited PIC conversions. If customers of a long distance company 
switch to another company, their PIC conversions will be provided by the LEC 
124 to the NLIS and Quick PIC systems 122. The NLIS and Quick PIC systems 

25 122 provide files of these conversions to the DSS 104. The DSS 104 in turn 
stores them, and allows CONI 106 to extract all recent PIC conversions and 
generate leads for a customer win-back campaign. 

2. CONI 

30 Referring to Figure 2, an exemplary internal architecture of CONI 

106 is shown. CONI 106 provides a graphical user interface (GUI) 160 for users 
to interact with CONI in at least two ways: to construct lead marts and to 
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perform queries or searches within such constructed lead marts. Considering 
first the query of lead marts, users such as a BSU 1 16 of the company, use the 
GUI to translate a marketing strategy into a marketing campaign. 

The BSU 116 first specifies criteria for targeting clients. For 
5 example, from a prior analysis performed on data in the data warehouse of the 
DSS 104, the BSU 116 may determine that people who have recently moved 
from California to Colorado, and have purchased a car in the past year, are likely 
to subscribe to cellular service and switch their long distance provider. As a 
result of this determination, the BSU 116 wishes to offer a long distance and 

10 cellular service package to these people under a telemarketing campaign. The 
BSU 1 16 uses the GUI 160 to input and specify that it wants to pull records of all 
clients who have (1) moved from California to Colorado, (2) have purchased a 
car in the past year, and (3) are not currently both long distance and cellular 
customers of the company. 

IS A campaign management process 162 receives the input data or 

criteria from the GUI 130 and translates such criteria into a lead qualification 
filter or file. For example, the campaign management process 162 builds a query 
from the input criteria using structured query language (SQL) statements. A 
query to produce a list of lead records is generally described herein as a 

20 "marketing campaign," as described below. 

A lead qualification filter process 164 receives the constructed lead 
qualification filter from the campaign management process 162 and applies such 
filter to data in the data warehouse of the DSS 104 (or in a lead mart 166) 
(discussed below) to extract a list of clients which meet the criteria specified by 

25 the lead qualification filter. The lead qualification filter process 164 employs the 
lead qualification filter to extract client records as "lead records" for a given 
marketing campaign, and stores such lead records together in a lead mart 166 
(described below). 

In the previous example, the lead qualification filter may first 

30 extract a first lead list of all client identifiers for clients who have moved from 
California to Colorado, then from this first list extract a second lead list of all 
clients who have purchased a car in the past year. From this second list, the lead 
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qualification filter then extracts a third, smaller lead list of all clients who are not 
currently both long distance and cellular customers of die company. The lead 
qualification filters may also extract other undesirable leads, such as clients who 
have requested to not be contacted ("suppressions") or clients whose age is 
5 greater than 100 (/. e. , probably deceased). 

In general, queries and retrieval of selected data from databases, 
data marts, and data warehouses under the exemplary embodiment of the present 
invention are performed using known database querying and retrieval techniques, 
such as using SQL statements and open database connectivity (ODBC), as is 

10 known by those skilled in the relevant art. 

The lead qualification filter process 164 also constructs lead marts 
166 in which to store the data extracted from the DSS 104 based on certain lead 
qualification filters. "Lead marts" 166 are databases, smaller than the data 
warehouse, which contain subsets of data from the data warehouse. In general, 

15 the lead marts 166 are customized collections of data extracted from the DSS 104 
for individual BSUs 116. As is described herein, the BSUs 116, in turn, query 
the lead marts to develop specific client lists for a given marketing campaign. 

Each lead mart 166 is typically a single-subject database used by 
individual groups of users, such as individual BSUs 116 in the company. 

20 Examples of such lead marts 166 for a long distance company, in a preferential 
order, can be a lead mart storing data of all customers of international alliances 
on partner programs (e.g., frequent flyer programs), a lead mart storing data of 
all customers who make frequent international calls to non-English-speaking 
countries, a lead mart with all customers who make frequent international calls to 

25 English-speaking countries, a lead mart of all previous customers who have 
recently switched to another long distance company, and a mass market lead mart 
of all customers of a particular service. These common lead marts 166 can be 
used to manage ongoing marketing campaigns. For example, a lead mart 166 of 
all previous customers who have recently switched to another long distance 

30 company would be very useful for managing an ongoing customer win-back 
campaign. The lead marts 166 may be embodied in a separate computer, such as 
a Sun Dox, manufactured by Sun Microsystems, but do not need to be. 
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In the exemplary embodiment, the lead qualification filter process 
164 provides a preferential order or hierarchy of lead marts 166 so that a given 
client is not identified in more than one lead mart (and thus not contacted 
repeatedly under various marketing campaigns). For example, the lead mart 166 
5 of customers of international alliances/partnerships has a higher ranking than the 
lead mart of customers who make international calls to English-speaking 
countries. 

The lead qualification filter process 164 can be setup to perform 
nominal or periodic processing. For example, the lead qualification filter process 

10 164 can be created to perform repeated data extraction from the DSS 104 based 
on a previously created lead qualification filter. Thus, on a periodic basis (e.g., 
daily), die lead qualification filter process 164 periodically queries and extracts 
client records from the DSS 104 (via data warehouse shipping (described below)) 
that satisfy the lead qualification filter, and updates the corresponding lead mart 

15 166. Thus, die lead marts 166 continuously have currently updated data stored 
therein. 

The user or BSU 116 also uses the GUI 160 to input data or lead 
inventory specifications for creating specific client lists for implementing a given 
marketing campaign. For example, the user may input data to the GUI 160 

20 specifying how many lead records are to be formatted each day, to which 
TM/DM centers 118 certain lead records should be distributed, etc. A lead 
inventory management process 167 receives such input data from the GUI 160 
and uses the data to manage the extraction of and processing lead records from 
the lead marts 166. Thus, in a manner similar to that for the lead qualification 

25 filter process 164, the lead inventory management process 167 constructs a query 
based on data received from the GUI 160 and extracts lead records stored in one 
or more of the lead marts 166 based on a given marketing campaign to produce a 
"lead list" or list of lead records selected based on the given marketing campaign. 
The lead inventory management process 167 stores the resulting lead list and 

30 corresponding lead records in the CLR 108. 

While the lead list typically includes a list of lead records, each 
lead record includes not only the client identifier for a given lead, but also 
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additional information regarding the client, such as a number of times, and 
associated dates, when the client was contacted, and a code number 
corresponding to a marketing campaign during which the client was contacted. 
Generally, leads or clients can be tracked within CONI 106 based on a marketing 
5 campaign code created when a marketing campaign is created Furthermore, the 
lead inventory management process 167 stores lead distribution records for each 
marketing campaign. The lead distribution records identify which TM/DM 
center 118 a given lead record is to be distributed (or has been distributed). 
More than one lead distribution record can be associated with one lead record, 

10 since a client under the lead record can be associated with more than one 
marketing campaign. The lead inventory management process 167 creates lead 
distribution records for the given marketing campaign which specifies how many 
lead records are to be formatted each day, to which TM/DM centers 118 certain 
lead records should be distributed, etc. 

15 The lead inventory management process also performs certain 

screening processes such as ensuring that duplicate client records are not 
retrieved and stored in the CLR 108. The lead inventory management process 
107 ensures that a given client is not identified in two separate marketing 
campaigns (and thus is not called twice). The lead inventory management 

20 process 167 flags each client identified under a lead list in the CLR 108. If a 
subsequent lead list identifies a client already flagged in the CLR 108, the lead 
inventory management process 167 compares a hierarchy or rating of the new 
lead list to that of the former lead list which previously flagged the given client. 
If the subsequent lead list has a higher ranking than the prior lead list, then the 

25 client is flagged for the new lead list Thereafter, the lead inventory management 
process, via a formatter (described below), cancels a lead record previously 
forwarded to the TM/DM center 118 under the prior lead list. Thus, the lead 
inventory management process 167 can dynamically adjust ongoing marketing 
campaigns so that more successful campaigns (higher priority campaigns) preside 

30 over and accumulate clients from other campaigns. 

In general, CONI 106 provides two types of data retrieval 
granularity to the BSUs 116. Under a coarse granularity, the BSU 116, through 
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the GUI 160, campaign management process 162 and lead qualification filter 
process 164, extract a subset of client data from die DSS 104, and stores such 
data in a lead mart 166. In a finer granularity process, the BSU 1 16, through the 
GUI 160 and processes 162 and 164, develop a subset of client data stored in a 
5 lead mart 166 to produce lead lists and extract lead records for certain marketing 
campaigns. 

Summarizing, the campaign management process 162 creates lead 
qualification filters based on queries or criteria input by the BSU 1 16. The lead 
qualification filter process 164, in turn, implements such created lead 

10 qualification filters to extract the appropriate data from the DSS 104 (to construct 
lead marts 166) or from the lead marts (to construct lead lists). The campaign 
management process 162 provides an interface between the GUI 160 and the lead 
qualification filters process 164, while the lead qualification filters process 
interacts with the databases/data warehouses. 

15 A formatter process 168 receives client data that is extracted from 

the CLR 108 and DSS 104 based on a lead list for a given marketing campaign. 
The formatter process 168 matches the client identifier of each entry in the lead 
list with a name, address (if for a direct mail campaign), and telephone number 
(if for a telemarketing campaign) to create an appropriate lead record to be 

20 ultimately used to contact the client. The formatter process 168 obtains the 
name, address, and telephone number assignments for client identifiers from 
CARMA 102 via the DSS 104. As shown in Figure 3, the DSS 104 includes an 
operational data store (described below) that extracts this information from 
CARMA 102 and feeds it to CONI 106. 

25 The formatter process 168 formats the resulting leads into lead 

records, and lead distribution records that include an identification and address of 
specific TM/DM centers 1 18 to which each lead record is to be distributed; this 
information is provided by the lead inventory management process 167. The 
formatter process 168, in the exemplary embodiment, is table driven, and thus 

30 employs definition files, similar to templates. Such definition files specify die 
location of data retrieved by die formatter process 168 for display to agents at the 
TM/DM centers 118. For example, the definition file can specify that column 1 
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include phone numbers, column 2 include names, etc. By being table driven, the 
formatter process 168 does not require underlying code to be changed if a given 
lead record format is to be changed. Instead, only the definition file needs to be 
changed in order to change the way in which data extracted from the DSS 104 is 
5 displayed to agents at the TM/DM centers 1 18. 

The TM/DM centers 118 receive formatted lead records from the 
formatter process 168. Agents at the TM/DM centers 118 then contact clients 
identified in such records and record the results of such contacts. 

A contact management process 169 receives the results of the 

10 contacts from the TM/DM centers 118. In the exemplary embodiment, the 
results of such contact consist o£ or include, certain predetermined codes. Such 
codes indicate whether a client is to be a suppression, whether the client is to be 
contacted again and at what time, and any changes to be made to the client's 
profile. Thus, the contact management process 169 arranges a follow-up with a 

15 lead if needed, updates stored data, etc. The contact management process 169 
forwards the code and or information to the data warehouse of the DSS 104 for 
storage. The contact management process 169 thereby provides feedback on the 
results of the marketing campaign. The feedback provided by the contact 
management process 169 provides historical information to CONI 106. Such 

20 historical data can be accessed, via CONI 106, by the BSU 1 16 to determine how 
successful a given marketing campaign is. The BSU 116 can then modify a 
given marketing campaign to help improve its success, if needed. 

The CONI 106 is described in more detail in co-pending 
application entitled "System And Method For Automated Lead Generation In 

25 Client Contact Management For Sales And Marketing Platform," which was filed 
on even date herewith, which is assigned to a common assignee with the present 
application and which is explicitly incorporated by reference herein. 

3. CARMA 

30 CARMA 102 may be run on a number of different types, of 

computer systems. Figure 5 is a block diagram illustrating a computer system 
240 that is suitable for running CARMA 102. A mid-range computer that 
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employs the DEC Alpha processor from Digital Equipment Corporation of 
Maynard, Massachusetts, is suitable for running CARMA 102. Computer system 
40 includes a central processing unit (CPU) 242 that is responsible for overseeing 
operation of the computer system. The computer system 240 may include a 
5 number of peripheral devices, such as a video display 244 and an input device 
246. The computer system 240 may also include a network adapter 248 for 
interfacing the computer system with a local area network. A modem 250 may 
be provided in the computer system 240 to facilitate communications with 
remote computing resources over conventional telephone lines. The computer 

10 system 240 may include a number of different types of storage 252, including 
primary storage and secondary storage. The storage 252 holds a client database 
256 and a copy of the program code 254 for CARMA. Those skilled in die art 
will appreciate that the computer system 240 may be alternatively a 
multiprocessor system or a distributed system. The present invention is not 

15 limited to being practiced on a single processor system. 

The client database 256 has a logical architecture like that depicted 
in Figure 6. The client database 256 contains a number of different tables, where 
each table contains different information regarding a client. Each client is 
assigned a unique client identifier (client id). This client identifier links 

20 information that is kept in the different tables about the client. The linked 
records for a client in aggregate, constitute die client profile for the client. The 
three primary tables in the client database 256 are the client table 260, the 
address table 282, and the domestic phone table 290. Each record in the client 
table 60 contains information about a client, such as client ID, social security 

25 number, name, and professional title. The address table 282 holds information 
about the client's address, whereas the domestic phone table 290 holds 
information regarding a client's phone number and phone service. 

It should be appreciated that there may be a one to many 
relationship between the client table 260 and the address table 282, as well as 

30 between the client table 260 and the domestic phone table 290. A client may 
have multiple addresses and multiple phone numbers associated with it. Each of 
die addresses has a separate record in the client address table 280 and each of the 
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domestic phone numbers has a separate record in the domestic phone table 290. 
The client table 260 and the address table 282 are linked by an intermediate 
table: the client address table 280. Each address of a client has a record in the 
client address table 280 that is linked to the client table 260 by "clntjdr". Each 
5 address has a status indicator ("adrstat") within the client address table 280. 
The address status indicator may have a value of "active" or "obsolete." This 
status indicator is useful in tracking a client as a client moves among addresses. 
An address identifier ("adrjd") is held in the client address table to link the 
record and the client address table to the address record in the address table 282. 

10 The client phone table 276 serves as an intermediate table between 

the client table 260 and the domestic phone table 290. For each phone number or 
client, the client phone table 276 contains a phone number in three fields: "npa," 
"nxx," and "line." 

Suppression tables are also provided for the intermediate tables 

15 (e.g., die client address table 280 and the client phone table 276). In particular, 
the client address supp table 284 holds suppression information regarding a client 
address. Similarly, the client phone supp table 288 holds suppression 
information regarding a client phone number. The phone supp table 292 holds 
suppression information regarding records stored within the domestic phone table 

20 290. Analogously, the address supp table 288 holds suppression information for 
records stored in the address table 282. Household enhancement information is 
stored within the address enhancement table 286. Enhancement information for 
clients may be stored in the client enhancement table 274. 

A client account table 266 tracks internal account numbers for the 

25 client. There may be a one to many relationship between the client table 260 and 
the client account table 266. In other words, information about multiple accounts 
may be stored for a given client. 

A client member table 270 tracks a client's memberships in affiliate 
clubs, affinity clubs, and various other clubs. Examples include airline frequent 

30 flyer clubs, professional organizations, auto clubs, credit cards, travel clubs, 
health clubs, and the like. There may be relationships between records in the 
client member table 270 and records in the client table 260. 
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The client prov detail table 272 holds detailed audit information 
regarding the service provider, such as a client's phone number, address and 
name, as provided by each source. The client enhancement table 274 holds 
enhancement information regarding clients. The client language table 278 holds 
5 information regarding the natural language that the client speaks and/or 
understands. Multiple client language records may be provided for a single 
client The client list table 262 serves as an intermediate table for linking a client 
as identified by a client identifier with a list record in the list table 261 which 
defines all sources (lists) by which a client has been received 

10 As was mentioned above, CARMA 102 is able to process input 

data for multiple data sources and to update the data in the client database 256 
accordingly. This process of handling new input data will be described below 
relative to Figures 7 and 8. New input data is processed in load transactions. 
Initially, the raw input data is received at CARMA 102 from the data providers 

15 1 10 (step 320 in Figure 8). As was mentioned above, the data providers may be 
both external and internal and may provide a variety of different types of 
information. A scheduler 300 is responsible for invoking the respective stages of 
processing performed by CARMA 102. The scheduler 300 initiates and monitors 
the data load process upon receipt of the data. The scheduler initially causes 

20 formatting and data hygiene to be performed on the raw input data (step 322 in 
Figure 8). This formatting and data hygiene is performed by a stage load process 
302 (Figure 7). The stage load process 302 performs standardization of names 
and addresses of clients. The stage load process ensures that client identification 
(in the form of a name, social security number, or other common identifier) is 

25 valid and that certain information, such as mailing address, is valid and in a 
proper format. 

In the preferred embodiment of the present invention, CARMA 
102, PostalSoft's TrueName 304 product and the ACE product 305. Mapping 
mechanism 303 determines which of the products 304 and 305 are used or input 
30 data. TrueName 304 standardizes, parses, corrects, translates, appends, and 
validates name/address information in the data input from the data providers 110. 
In general, PostalSoft parses all billing names and address information into 
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standard name and address database attributes. ACE 305 also performs standard 
billing address append functionalities, such as die identification and attachment 
of full nine digit zip codes, carry routes, geographic match codes, and check 
digits for bar-coding. Street suffix values unit designators are also standardized 
5 by TrueName. TraeName 304 maintains a reference list of first names and 
associates a gender code with each first name (/.e., male, female). 

The preferred embodiment of die present invention also includes a 
number of custom coded edits or translations 306 that embellish the PostalSoft 
product 304. For example, the name information is always placed at the 

10 beginning of the output. Invalid characters are not permitted in names and extra 
blanks are eliminated in names and addresses. Literals such as "in care of or 
"attention of are deleted. Repeated names within first name fields and last name 
fields are deleted. Invalid names are eliminated. This may include the 
elimination of profanity and repetitive characters. The name components of 

IS input are removed if the hygiene score is below a predefined threshold value. 

Stage load process 302 outputs the validated standardized data to 
an interim data store 308. This enables a user to view and approve the data using 
the computer system 240 before the data is passed on to a final load process 3 10. 
The final load process 310 performs some additional processing of the data 

20 before data is added to the client database 256. 

The final load process 310 entails applying client matching 
algorithms 3 12. These client matching algorithms 3 12 are applied to determine if 
the client identification information that is provided and the data matches an 
existing client in the client database (step 324 in Figure 8). Figure 9 is a flow 

25 chart illustrating in more detail how the client matching rules are applied. First, 
critical matching criteria is examined for records in the client database 256 and 
information contained in the input data. Values that indicate the matching 
condition for each of a number of different criteria are assigned (see step 334 in 
Figure 9). 

30 The critical matching criteria include a social security number 

matching (SSN) criteria. The value for the social security number matching 
criteria may be "Y", indicating that there is a match and that both the input data 
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and the record in the client database 256 include a populated social security field 
The value may also be "N" indicating that there is no match but that the input 
data and the database record include a social security number value The value 
may lastly be "B*\ indicating that one or both of the input data or the database 
5 record do not contain a social security number value. 

Last names are compared to determine a value for a last name 
match (LNM) matching criteria. A value of "Y" for the LNM criteria indicates 
an exact match excluding spaces and special characters, identified misspellings, 
and hyphenated last names for married women. A value of "N" indicates no 
10 match and that a last name is provided both in the input data and die database 
record. 

First names are compared in obtaining a value for a first name 
match (FNM) criteria. A value of "Y" indicates an exact match including 
equivalent nicknames, abbreviations, and identified misspellings. An exact 

15 match may also be found where the first letter of the first name, including 
equivalent nicknames and abbreviations, match but only if the input data or the 
database record has a first name as an initial. Lastly, an exact match can be 
found if it matches to a nickname table entry. A value of "N" indicates that there 
is no match and that a first name is specified in both the input data and the 

20 database record. 

Middle names are compared to yield a value for a middle name 
match (MNM) criteria. The MNM criteria may have a value of "Y", which 
indicates an exact match, equivalent nicknames and equivalent abbreviations. A 
value of **N" indicates that there is no match and that a middle name is specified 

25 in both die input data and the database record. A value of "B" indicates that one 
or both of the input data in the database record are not populated with a middle 
name. 

Gender is compared in the gender (GDR) matching criteria. A 
value of "1ST indicates that no match is found between a male, female, or 
30 company genders in both the input data and die database record. A value of "A" 
indicates that the input data or die database record is populated with an 
ambiguous gender value. A value of "NT indicates that both die input data and 
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Ae database record are populated with male gender codes. A value of T" 
indicates that both the input data and the database record are populated with 
female gender codes. A value of "C indicates that both sources are populated 
with company gender codes. 
5 Tides of clients are compared to yield a value for the tide (TTL) 

matching criteria. A value of " Y" indicates an exact match on a courtesy title or 
match of equivalent ambiguous values. For example, the abbreviation "Mrs." 
matches "Ms." A value of "N" indicates that there is no match and that both die 
input data and the database record are populated with courtesy titles. A value of 

10 "B" indicates that the input data or the database record or both are not populated 
with a courtesy title. 

Zip codes are compared to yield the value for a zip code matching 
criteria (ZIP). A value of "9" indicates an exact match of a full nine-digit zip 
code. A value of "7" indicates a match on the first seven digits of a zip code. A 

15 value of "5" indicates a match on the first five digits of a zip code. A value of 
"N" indicates no match and that both the input data and the database record are 
populated with zip codes. 

Street names and street suffixes are compared in the street names 
and street suffixes (STR) matching criteria. A value of "Y" indicates an exact 

20 match of street names and street suffixes. A value of "N" indicates no match and 
that both the input data and the database record are populated or that one of these 
two is not populated. A value of "B" indicates that both the input data and the 
database record are not populated with a street name or a street suffix. 

An address number or P.O. Box number is compared to yield the 

25 value for the number (NBR) matching criteria. A value of " Y" indicates an exact 
match. A value of "N" indicates no match and that both the input data and the 
database record are populated by the same type of information. 

Apartment numbers are compared to yield the value for die 
apartment (APT) matching criteria. A value of "Y" indicates an exact match. A 

30 value of "N" indicates that there is not a match and that both the input data and 
the database record contain an apartment number specification. A value of "B" 
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indicates that the input data or the database record is not populated with an 
apartment number. 

Phone numbers are compared to yield a value for the phone number 
(PHN) matching criteria. A value of "Y" indicates an exact match of phone 
5 numbers. A value of "NT indicates that there is not a match and that both the 
input data and the database record contain phone numbers. A value of "B" 
indicates that either the input data or the database record do not contain a phone 
number. 

Account numbers are compared to yield the value for the account 
10 number (ACC) matching criteria. A value of "Y" indicates an exact match where 
both the input data and the database record are populated with an account 
number. A value of "N" indicates that the input data and the database record 
contain account numbers and that there is no match between the account 
numbers. A value of "B" indicates that one or both of the input data and the 
15 database record are not populated with an account number. 

Membership numbers are compared to yield a value for the 
membership number (MEM) criteria. A value of tt Y" indicates an exact match 
on a specific membership number. A value of "N" indicates that there is no 
match and that both the input data and the database record are populated with the 
20 same type of membership number. A value of "B" indicates that one or both of 
die input data and the database record are not populated with the membership 
number. 

Client_id*s may be compared to yield a value for the client id 
matching criteria. A value of "Y" indicates an exact match where both the input 
25 data and the database record are populated with clientjds. A value of "N" 
indicates that there is no match and that both the input data and die database 
record are populated with clientjds. A value of M B" indicates that one or both of 
the input data and the database record are not populated with a client ID. 

It should be noted that each of these matching criteria may also 
30 assume a value of indicating that the determination of whether there is a 
match or not is not dependent upon that criteria. 
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The values are utilized by applying match rules using a match rule 
tables to determine if there is a match (step 336 in Figure 9). An example of 
match rule is as follows: 
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I = SSN 2 = LNM 3 = FNM 4 = MNM 5 = GDR 6 = TTL 
7 = ZIP 8 = STR 9 = NBR 10 = APT 

II = PHN 12 = ACC 13 = MEM 14 = CLN 

Each row within the match rule table contains a scenario and a 
result (note the columns labeled "scenario" and "result-rule"). Each row may be 
considered a separate rule. Each other column specifies a particular value for 

10 one of the 14 match criteria described above (see the Legend above). If the 
criteria have the value specified in die columns, then die rule is fulfilled and the 
result of the rule is applied. For example, scenario 113 specifies that if there is a 
last name match (column 2 is "Y"), there is a first name match (column 3 is 
"Y"), there is a middle name match (column 4 is "Y"), both the input data and 

15 die database record are populated with male gender codes (column 5 is "M"), one 
or both die sources are not populated with a courtesy title (column 6 is "B"), 
there is a zip code match (column 7 is T), there is a street name and street 
name suffix match (column 8 is "Y"), there is a number match (column 9 is "Y") 
and there is an apartment match (column 10 is "Y"), it is determined that the 

20 input data and the database record match. As a result, a determination is made in 
step 326 of Figure 8 of whether there is a match or not by applying the match 
rule tables. 

It should be appreciated that there are a number of different 
combinations or scenarios within the match rule table that could be categorized 
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into the categories 339 set forth in Figure 10. In particular, the match rule table 
contains the following combinations: name and address combinations 340, name 
and phone combinations 342, name and social security number combinations 
344, name and account combinations 346, name and membership number 
5 combinations 348, name and client ID combinations 350, address and phone 
combinations 352, address and account combinations 354, address and 
membership number combinations 356, phone and account combinations 358, 
phone and membership number combinations 360, and account and membership 
number combinations 362. 

10 If it is determined in step 326 that there is not a match between the 

input data and any database records that hold client profiles, a new record may 
be created and a new client identifier is assigned to the client (step 328 in Figure 
8). The new record is filled in with the data that is provided in the input data that 
has been processed by the stage load process 302. 

15 In contrast, if a match is found, an overlay process is applied to 

determine how to resolve the conflict between the client information contained in 
the input data and the client database record (step 330 in Figure 8). In general, as 
will be described in more detail below, the overlay process applies overlay rules 
and resolution rules to determine how to resolve the conflicts and the data is 

20 updated accordingly within the client database 256 (step 332 in Figure 8). This 
overlay process is depicted as overlays 314 in Figure 7 and results in data that is 
passed to the client database 256. 

Figure 11 depicts different varieties of overlay rules 364 that are 
provided by CARMA 102. There are client overlay rules 366. The general 

25 approach of the client overlay rules is after receiving an indication that there is a 
match, the name fields in the client database 256 are only updated if the input 
data has more complete information. The client overlay rules contain specific 
rules directed to fields in the client table 260. The active address overlay rules 
368 specify how active address information within the client database 256 should 

30 be overlaid relative to input data that matches. The informational address 
overlay rules 370 specify how informational address information should be 
overlaid. The phone number overlay rules 372 specify how phone number 
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information should be overlaid. The enhancement overlay rules 374 specify how 
enhancements should be overlaid. The list specific database table overlay rules 
specify what database tables are allowed to be updated for any specific load feed. 
Lastly, die client jprovider detail overlay rules indicate how client provider 
5 information in the database 256 should be overlaid. 

Once a client database 256 has been updated, the changes may be 
replicated by a client database replication process 3 16 and may be passed on to a 
data harvesting facility 380 for an operational data store 384 managed by the 
DSS 104. Changes are captured by a changed data capture process 318 that 
10 forwards the changes to die data harvesting facility 380 of the data warehouse 
823 of DSS 104. 

Therefore, CARMA 102 provides an integrated system for client 
profile management that provides a number of unique features. CARMA tracks 
individual clients as individuals for other than as telephone numbers or addresses 

15 so that multiple clients that share telephone numbers or addresses may be 
tracked. CARMA 102 maintains multiple relationships, including multiple 
addresses per client and multiple phone numbers per client. This facilitates 
complete tracking of clients having multiple phone numbers or addresses. 
CARMA 102 provides continuous ongoing tracking of clients and readily 

20 facilitates changes to client profiles. CARMA 102 includes processing resources 
for accepting and using input data of almost any type in any format. Still further, 
CARMA performs effective client matching to avoid duplicate client profiles. 

4. Data Flow 

25 Figure 12 illustrates the data flow in the SaMS infrastructure 100. 

Process steps or data flow in Figure 12 are identified by reference numbers 1 
through 24 below and in Figure 12. The paragraphs set forth below are 
introduced by a number, 1 through 24, which corresponds to the data flows 
shown in Figure 3. Where relevant, certain hardware or processes are also 

30 described with respect to the data flows 1 through 24. 

1. Client information from the data providers 110 is collected 
by CARMA 102. As noted above, the client information from the data providers 
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110 can include internal data sources such as the company's customer traffic, 
billing system records, client contact records, etc., as well as external data such 
as syndicated lifestyle information. CARMA 102 is designed to accept data in 
practically any format and from any source. CARMA 102 uses input client 
5 information to update client profiles in its client database. 

2. Any changes to client profiles in CARMA 102 (generally a 
result of new client information input by the data providers 1 10) are captured and 
fed to the DSS 104. Specific client identification data, such as names and 
addresses, are withheld. Instead, CARMA 102 provides generic client identifiers 

10 to die DSS 104. The DSS 104 uses a data harvesting process 380 to collect and 
format all input data, whether from CARMA 102 or any other data provider. The 
data harvesting process 380 includes processes for identifying, extracting, 
transforming, deriving, aggregating, integrating and conducting integrity checks 
of data collected from the data providers 1 10. 

15 The identifying process identifies what data elements within the 

collected data are needed for downstream processes, as well as identifying a 
definitive source for collected data, not necessarily the first known source. The 
extracting process copies appropriate data from the data providers 110. The 
transforming process reconciles the various ways that the same data is labeled as 

20 it is received from the data providers 110. For example, values for a client's sex 
under one data provider or system may be in the form of "m" or "f," while from 
another data provider be in the form of "1" or "2." The transforming process 
may instead assign a new value, such as "male" and "female." 

The deriving process converts some data into another value. For 

25 example, two or more fields of data about a client may be converted to a score 
(e.g., the address and income of a client combined and represented by a two-digit 
score). The aggregating process combines and summarizes data across a set of 
transactions or a set of individual clients. For example, the total monthly long- 
distance spending by a client may be aggregated over a year to provide an 

30 average monthly spending value for that client. The integration process matches 
data with the appropriate client number, and verifies time frames for each piece 
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of data. The integrity check process ensures that data stored in the data 
warehouse is in the appropriate form/format 

3. The data harvesting process 380 collects from various data 
providers 1 10 information for which specific client identification is not needed. 

5 This information can be used to identify general trends. 

4. The data harvesting process 380 stores all the data it collects 
in a data warehouse 382. The data warehouse 382 may be partitioned and 
configured in various schemes to suit the needs of die business utilizing it For 
typical businesses, such as a telecommunications company, it must be capable of 

10 storing huge volumes of data, perhaps several Terabytes. The data warehouse 
382 preferably employs a massive parallel processing (MPP) platform, such as 
"more than 100" IBM SP2 processors. A scaleable database management system 
is preferably used, such as that offered by Informix Corporation. 

5. and 6. A data shipping process 386 extracts specific data from 
IS the data warehouse 382 and places this data in data marts 388. The data marts 

388 are smaller databases that house subsets of data from the data warehouse 
380, and are used to facilitate quick and easy access to the data stored in the data 
warehouse. The data marts 388 each preferably employ symmetrically parallel 
processor (SMP). Each data mart 388 is setup for an individual customer or user 
20 of the DSS 104. For example, one data mart 388 can be established for a 
residential marketing BSU 116, and another data mart established for a small 

A 

business group BSU 116. 

A user of the DSS 104, such as a BSU 116, specifies in the data 
shipping process 386 what data they wish to have placed in their data mart 388 

25 from the data warehouse 382, and when. The BSU 116 specifies such criteria via 
a DSS user interface process 390 (described below). The data shipping process 
174, on a periodic basis, then extracts data from the data warehouse 382 under 
the user's specified criteria, and places this data in the user's data mart 388. 
Summarizing, the data shipping process 386 moves data from the central data 

30 warehouse 382 to departmental data marts 388 in a process similar to the data 
harvesting process 380 (e.g., users can select requested elements and require 
additional transformations be applied to data before it is stored in the data marts). 
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7. and 8. The DSS user interface process 390 is a tool that 
provides access to and analysis of data in the data marts 388. Users, such as a 
BSU 1 16, use the DSS user interface process 390 to perform queries into the data 
in their data mart, under a query process similar to that described above for 
5 CONI 106. For example, the data shipping process 386 may extract from the 
data warehouse 382 data representing all clients who have recently moved to the 
United States from a foreign country, and place this data in one of the data marts 
388 for the BSU 116. The BSU 116 then uses the DSS user interface process 
390 to obtain a list, from this data, of all of these clients who moved to California 

10 from Japan, and have selected another long distance company. 

Generally, more complex methods of analysis are used to 
determine what types of marketing campaigns can be successful. The BSU 1 16 
examines their data mart 175 to find significant patterns and relationships that 
can be translated into marketing strategies. Using the DSS user interface process 

15 390, the BSU 116 formulates queries and performs the necessary analysis of data 
in their data marts 388 to develop marketing strategies and therefrom determine 
what sort of marketing campaigns to implement. Queries against data in the data 
warehouse 382 are made using SQL or other query language. 

The BSUs 116 preferably includes minicomputers or workstations, 

20 such as Sun Microsystems SC2000/SPARC20 system. Such microcomputers 
preferably operate under a UNIX operating system, and run a database 
management system such as that offered by Informix. The minicomputers (as 
well as other elements within the SaMS infrastructure 100) are coupled using 
high-bandwidth connections. For example, the minicomputers of the BSUs 116 

25 are preferably coupled to the DSS 104 and CONI 106 using fiber-optic 
distributed data interface (FDDI) local-area network connections. The 
minicomputers preferably communicate to the infrastructure 100 using ODBC. 

The BSUs 116, in the exemplary embodiment, employ a World 
Wide Web browser to access hypertext markup language (HTML) applications 

30 on the DSS 104 and/or CONI 106. The HTML applications provide a menu of 
data views and other screens, under a GUI environment (to the BSU 1 16), as 
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described herein. Thus, the BSUs 1 16 access portions of die SaMS Infrastructure 
100 via an intranet, or via the Internet. 

9. Once the BSU 116 has analyzed data and determined a 
marketing strategy, they use CONI 106 to implement that strategy as a marketing 

5 campaign that is targeted for a specific client segment. The campaign 
management process 162 and GUI 160 within CONI 106 provide the ability for 
the BSU 1 16 to state their marketing campaign as specific criteria. 

10. Data input through the GUI 160 to the campaign 
management process 162 is converted by the campaign management process into 

10 lead qualification filters under the marketing campaign. The lead qualification 
filters are then input to the lead qualification filters process 164. The lead 
qualification filters process 164 is the interface between the data shipping 
process 174 of the DSS 104 and CONI 106. The lead qualification filters specify 
criteria that clients need to meet in order to be included in the marketing 

IS campaign. 

11. The lead qualification filters process 164 extracts data from 
die data warehouse 172 based on criteria that represents die BSU 116's 
marketing campaign (under the lead qualification filter). Alternatively, the lead 
qualification filters process 164 applies the lead qualification filter to extract data 

20 stored in the lead marts 166. 

12. Client records that meet all lead qualification filter criteria 
are placed in the lead marts 166 as related lead records. The lead marts 166 are 
CONI 106 data marts housing client records or lead records for particular 
marketing campaigns. From the lead records, formatted lead records will be 

25 generated (as discussed herein). There may be multiple lead marts 166, but only 
one record of a single client is preferably stored in one of them. 

13. The lead inventory management process 164 creates a lead 
list based on the lead records selected by the lead qualification filter. 
Additionally, the lead inventory management process 164, under direction from 

30 data input from the BSU 116, creates lead distribution records that specify the 
number of lead records to make available for calling or mailing, specify which 
TM/DM centers 118 receive each lead record, specify whole numbers of lead 
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records to assign to each TM/DM center, etc. The BSU 1 16 can use the lead 
inventory management process 164 to specify where leads are to be sent, based 
on agent skill sets, geography, resources available, etc., thereby allowing the 
TM/DM centers 118 to manage their resources better. The lead inventory 
5 management process 164 also ensures that each client is extracted only once 
from all of die lead marts 166, ensuring no client duplication in various lead lists. 

14. The lead inventory management process 164 feeds the lead 
list and associated lead records and lead distribution record for storage in the 
CLR 108. The CLR 108 maintains lead records for each client throughout the 

10 marketing campaign, including previous contacts and results of contacts under 
the feedback data flows described herein. The lead inventory management 
process 167 tracks leads on clients that have recently been provided to a TM/DM 
centers 118, to ensure frequent contacts are not made to the same client and 
updates lead records in the CLR 108 accordingly. For example, if a lead record 

IS on a specific client is passed to a first TM/DM center 118 on one night, and 
another lead record on the same client is provided to CLR 108 from the lead 
inventory management process 167 die next night, the lead record in CLR 108 
will either indicate on the second lead record that this is a second lead record for 
the same client in two nights, or an indication will not pass this lead to another 

20 TM/DM center 118. 

15. The DSS data harvesting process 380 collects from CARMA 
102 a feed of specific data associated with or assigned to client identifiers such 
as name, address, and telephone numbers. 

16. This specific data is placed in an operational data store 
25 (ODS) 384. The ODS 384 is similar to the data warehouse 382, but is generally 

much smaller. A purpose of the ODS 384 is to store data temporarily, in order to 
distribute data to other processes or systems. 

17. and 18. Upon request by the formatter process 168, the data 
shipping process 386 extracts from the ODS 384 the specific data, such as the 

30 name, address, and telephone number, assigned to the client identifiers in the 
lead records, and provides this data to die formatter process. The formatter 
process 168 uses this data to assign a name and telephone number, and possibly a 
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mailing address, to each client identifier that was provided by die lead inventory 
management process 164, and create formatted lead records. 

19. The formatter process 168 retrieves the lead records 
associated with the lead list from the CLR 108 and constructs formatted lead 

5 records using the client data provided by the data shipping process 386. 
Formatted lead records may include some or all of the following data: client 
names, telephone numbers, addresses, contact history, TM/DM centers 118 
assignment, and other information pertinent to die marketing campaign. The 
formatter process 168 formats lead records by matching client identifiers, which 
10 are received by the lead inventory management process 164, with names and 
telephone numbers from CARMA 102. 

20. The formatter 168 forwards the formatted lead records to the 
appropriate TM/DM centers 118 based on the lead distribution list The TM/DM 
centers 118 import such lead records and contact the clients and conduct the 

15 marketing campaign, such as offering long distance services or products. 

21. The results of each client contact are recorded locally at the 
TM/DM centers 118. 

22. The results of each client contact are extracted by or 
forwarded to the contact management process 169 within CONI 106 from the 

20 TM/DM center 118. The contact management process 169 can arrange follow- 
up leads and report on status or results of a given campaign. The contact 
management process 169 may automatically update lead records stored within 
the CLR 108. 

23. The contact management process 169 provides results of 
25 client contacts to the data harvesting process 380, so that the data warehouse 382 

can be updated with these results. The data shipping process 386 then updates 
die corresponding data in the data marts 175. This represents another of many 
feedback loops built into the SaMS infrastructure 100. As noted above, the BSU 
116 formulates and conducts a marketing campaign. The results of each client 
30 contact under the campaign are fed to the data warehouse 382. The BSU 1 16 can 
then extract and analyze the results of the overall campaign by specifying to the 
data shipping process 386 an extraction of certain client data. From this, the 
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BSU 116 may formulate another campaign, modify an existing campaign, or 
identify an unexpected response to the previous campaign. 

For example, the BSU 116 may formulate a campaign to sell long 
distance service to a certain RBOC's customers. Many customers, when 
5 contacted by a TM/DM center, may respond with a preference to switch local 
service providers. These responses are recorded in the CLR 108, extracted by 
the contact management process 169, collected by the data harvesting process 
380, and stored in the data warehouse 382. The BSU 116 then analyzes the 
results of their campaign via the DSS user interface process 390 and previously 

10 updated data marts, and determines that a local service marketing campaign to 
those same customers is needed. 

The TM/DM centers 118 can also perform direct mail campaigns. 
For example, CONI 106 can instruct the TM/DM center 1 18 to mail brochures to 
selected clients, wait two weeks, then call those clients. 

15 24. The result of a client contact may be that the client requests 

to not be called again (a "suppression"). As noted above with respect to data 
flow 22, the contact management process 169 updates the lead records in the 
CLR 108 to indicate a suppression for the client. An extraction of all 
suppressions are then fed, as a Data Provider, to CARMA 102. CARMA 102 in 

20 turn will feed these suppressions, by client identifier only, to the data warehouse 
382. The lead qualification filter process 164 can then filter out any clients with 
a suppression indicator in future campaigns. Suppressions can also be provided 
to CARMA 102 from External Data Sources 1 14, such as a LEC 124. 

While the present invention has been described with reference to a 

25 preferred embodiment thereof those skilled in the art will appreciate that various 
changes in form and detail may be made without departing from the intended 
scope of the present invention as defined in the appended claims. 
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CLAIMS 

1. An automated marketing system, comprising a client profile 
management system for managing client profiles that contain information about clients 
for marketing contact; 

a data warehouse system for storing data regarding clients; and 
a contact infrastructure for querying the data warehouse to automatically 
generate leads of clients to contact by telemarketers wherein the querying entails 
filtering data in the data warehouse to ensure that the generated leads are for clients 
that include certain characteristics. 

2. The automated marketing system of claim 1 wherein the client 
profile management system includes a client profile database and a database 
management system. 

3. The automated marketing system of claim 1 wherein the client 
profiles include a client profile that specifies multiple phone numbers for a client. 

4. The automated marketing system of claim 1 wherein the client 
profiles include a client profile that specifies multiple addresses for a client 

5. The automated marketing system of claim 1 wherein at least one 
of the clients is a business. 

6. The automated marketing system of claim 1 wherein the client 
profiles include a first client profile for a first client and a second client profile for a 
second client and wherein the first client and the second client share a single telephone 
number that is stored in both the first client profile and in the second client profile. 

7. The automated marketing system of claim 1 wherein the client 
profiles include a first client profile for a first client and a second client profile for a 
second client and wherein the first client and the second client share a single 
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residential address that is stored in both the first client profile and in the second client 
profile. 

8. The automated marketing system of claim 1, further comprising a 
feedback mechanism for feeding results of contacting clients to the data warehouse 
and the client profile management system. 

9. The automated marketing system of claim 8, further comprising a 
suppression mechanism for suppressing a selected client from being designated as a 
lead in response to results of contacting the selected client. 

10. The automated marketing system of claim 1, further comprising 
an automated order provisioning system for provisioning orders in response to an 
order resulting from a telemarketing contact. 

11. The automated marketing system of claim 1, further comprising a 
delivery mechanism for delivering the generated leads to at least one telemarketing 
center that has telemarketers. 

12. In an automated marketing system having stored data regarding 
potential clients, a computer-implemented method, comprising the steps of: 

providing a lead generator for generating leads of potential clients to 
contact by telemarketers from the stored client data; 

using the lead generator to generate leads for a first marketing campaign; 

obtaining results of contacting the generated leads; and 

using the obtained results to generate leads by the lead generator for a 
second marketing campaign. 

13. The method of claim 1 1 wherein the obtained results are used to 
suppress at least one client so that the client does not appear among the generated 
leads. 
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14. The method of claim 11 wherein the obtained results indicate 
whether a contacted client made a purchase in response to being contacted. 

15. In an automated marketing system, a method comprising the 
computer-implemented steps of: 

providing client information regarding potential clients for telemarketing 
contact on a per-client basis; 

querying the client information to generate a list of leads for 
telemarketing contact, each lead being associated with a potential client and 
containing contact information for the potential client that fulfills a first set of 
characteristics; and 

forwarding the leads to telemarketers. 

16. The method of claim 15, further comprising the steps of receiving 
new data from multiple data providers in multiple formats and integrating the new data 
with the provided client information to update the provided client information. 

17. The method of claim 15, further comprising the steps of receiving 
results of contacting the associated potential clients of the leads and storing the results 
with the provided client information. 

18. The method of claim 15 wherein the system includes a data 
warehouse and at least some of the client information is stored in the data warehouse. 

19. The method of claim 15, further comprising the step of again 
querying the client information to generate another list of leads for telemarketing 
contact, each lead being associated with a potential client and containing contact 
information for the potential client that fulfills a second set of characteristics. 

20. The method of claim 15 suppressing leads for a potential client 
that fulfill the first set of characteristics from the list of leads. 
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